Checklist

General

• I tested all changes and their related features with all corresponding user types on a test server.
• This is a small issue that I tested locally and was confirmed by another developer on a test server.
• Language: I followed the guidelines for inclusive, diversity-sensitive, and appreciative language.
• I chose a title conforming to the naming conventions for pull requests.

Server

• Important: I implemented the changes with a very good performance and prevented too many (unnecessary) and too complex database calls.
• I strictly followed the principle of data economy for all database calls.
• I strictly followed the server coding and design guidelines.
• I added multiple integration tests (Spring) related to the features (with a high test coverage).
• I added pre-authorization annotations according to the guidelines and checked the course groups for all new REST Calls (security).
• I documented the Java code using JavaDoc style.

Client

• Important: I implemented the changes with a very good performance, prevented too many (unnecessary) REST calls and made sure the UI is responsive, even with large data (e.g. using paging).
• I strictly followed the principle of data economy for all client-server REST calls.
• I strictly followed the client coding and design guidelines.
• Following the theming guidelines, I specified colors only in the theming variable files and checked that the changes look consistent in both the light and the dark theme.
• I added multiple integration tests (Jest) related to the features (with a high test coverage), while following the test guidelines.
• I added authorities to all new routes and checked the course groups for displaying navigation elements (links, buttons).
• I documented the TypeScript code using JSDoc style.
• I added multiple screenshots/screencasts of my UI changes.
• I translated all newly inserted strings into English and German.

Motivation and Context

This is a follow-up to the feature I’m working on: #9810. The goal is to provide instructors with clearer insights into the feedback given to students. In this PR, a “Group Feedback” feature has been introduced. This feature allows instructors to group similar feedback (similarity > 90%), ensuring that the table remains manageable without an overwhelming number of individual entries. This is particularly useful in scenarios where test cases utilize random values, leading to feedback that differs only slightly (e.g., by numbers) while the rest of the content remains identical.

Description

A new toggle was added along with a corresponding flag to indicate whether Levenshtein grouping should be applied. Depending on the toggle’s state (true or false), the server now either groups the feedback using Levenshtein or skips the grouping. Unfortunately, Levenshtein grouping can be resource-intensive (Cpu), which is why a loading indicator was added to enhance user experience during the processing (maximum waiting time of up to 10 seconds for very very large courses).

Additionally, since Levenshtein grouping cannot be applied directly within a query, manual pagination is required when the toggle is activated.

The Affected Students Modal has been refactored. It no longer attempts to send all feedback IDs but instead uses only the first five IDs for the feedback detail text. This change alters the way the modal is used, and it has therefore been renamed to Affected Students Sample, as it now displays up to five affected students per server request. The number 5 was chosen because five example repositories should be sufficient to identify the cause of specific bad feedback in a test case.

Steps for Testing

Prerequisites:

• 1 Instructor
• Student Sumbissions
• 1 Programming Exercise

1. Log in to Artemis
2. Navigate to a Course with Instructor rights
3. Create a Programming Exercise or use an existing one
4. Solve the Programming Exercise as Students, ideally with different kinds of Progress (You can use artemis test users for this)
5. Make sure you have two identical feedbacks in one testcase (similarity > 90 percent). You might need to adjust testcases by editing them for the programming exercises
6. Navigate as Instructor to the Grading of an Exercise
7. Navigate to the Feedback Analysis section
8. Verify that the table displays data correctly, and press the group feedback toggle
9. Verify that the two similar feedbacks were grouped into one feedback and count was updated correctly

Testserver States

Review Progress

Performance Review

• I (as a reviewer) confirm that the client changes (in particular related to REST calls and UI responsiveness) are implemented with a very good performance even for very large courses with more than 2000 students.
• I (as a reviewer) confirm that the server changes (in particular related to database calls) are implemented with a very good performance even for very large courses with more than 2000 students.

Code Review

• Code Review 1
• Code Review 2

Manual Tests

• Test 1
• Test 2

Performance Tests

• Test 1
• Test 2

Test Coverage

Screenshots

Before:

After:

Summary by CodeRabbit

Release Notes

• New Features

  • Introduced a grouping feature for feedback based on test cases.
  • Enhanced feedback detail structures to support multiple feedback texts and additional parameters.
  • Updated user interface elements, including modals and tables, for improved clarity and usability.
  • Added new properties and functionalities in various components to manage feedback more effectively.

• Bug Fixes

  • Resolved issues with loading states and data fetching logic in feedback analysis.

• Documentation

  • Updated localization files to reflect new features and improve user guidance.

• Refactor

  • Streamlined data structures and method signatures for better performance and maintainability.
  • Adjusted internal logic in services and components to accommodate new data formats.

• Tests

  • Expanded test coverage to include new feedback structures and grouping functionality.
  • Updated tests to reflect changes in method signatures and data formats.